Hi Ray,
I think I have a few ideas, but can you reproduce this? (Maybe with your amplifiers turned off).
But I just tested with KMotionCNC and noted several things. The "MSG" dialog box is not currently forced to be on top of all other Windows. The expectation is that you either Cancel (Abort) or OK (Continue) using the Displayed Dialog Box. But it seems you clicked on your Screen which probably hid the Interpreter's MessageBox behind your Screen.
Calling Interpreter.Halt() basically sets a flag in the Interpreter and In CoordMotion to request that GCode Execution Thread to do the Halt Sequence ASAP. The Halt is tested at various places while executing. But in this case the the Interpreter was frozen in the MessageBox so the Halt was not yet detected.
You then issued an MDI command to execute some GCode which would cause the GCode Interpreter to be re-entered. This could likely result in unpredictable behavior.
So you might verify if that sequence really happened. Possible solutions are for us to force the MSG MessageBox to be amodal so it must be used. But also your app should probably keep track of when it launched the GCode interpreter and disable many of the buttons that could interfere with the Interpreter or cause it to be re-entered. KMotionCNC sets a flag called ThreadIsExecuting which is set when Gcode is launched ornd cleared on the GCode Complete Callback.
Or maybe you have any other thoughts or ideas.
Regards
TK
| Group: DynoMotion |
Message: 3667 |
From: himykabibble |
Date: 2/1/2012 |
| Subject: Re: A Strange Thing Happened.... |
Tom,
What you describe is basically what I decided must have happened. I can see no other explanation for the A axis moving, as it is ONLY moved by tool comp commands. I do currently disable most of the controls when a program is running, but I want the Stop button to be sort a more polite E-Stop - whenever it is enabled (which is whenever the interpreter is running), you should be able to push it and be sure the machine will stop, and end up in a state from which you can resume what you were doing. I don't want the interpreter state to be totally tossed, but it would be perfectly acceptable to flush any commands in process, and re-start at a line boundary. Is there a way to accomplish that? I use this often when running a program for the first time. If I see it go off-course, I'd like to hit Stop, select the program line to resume from, and re-start the interpreter from that line. This is the behavior Mach3 provides, and I found it very useful.
While you're here, is there a way to fetch the currently active modal states from the interpreter? I'm not seeing anything in the APIs. I believe I did see something in the interpreter source code that is exactly what I need, but it doesn't appear to be brought out through the APIs.
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
> Â
> I think I have a few ideas, but can you reproduce this? (Maybe with your amplifiers turned off).
> Â
> But I just tested with KMotionCNC and noted several things. The "MSG" dialog box is not currently forced to be on top of all other Windows. The expectation is that you either Cancel (Abort) or OK (Continue) using the Displayed Dialog Box. But it seems you clicked on your Screen which probably hid the Interpreter's MessageBox behind your Screen.
> Â
> Calling Interpreter.Halt() basically sets a flag in the Interpreter and In CoordMotion to request that GCode Execution Thread to do the Halt Sequence ASAP. The Halt is tested at various places while executing. But in this case the the Interpreter was frozen in the MessageBox so the Halt was not yet detected.
> Â
> You then issued an MDI command to execute some GCode which would cause the GCode Interpreter to be re-entered. This could likely result in unpredictable behavior.
> Â
> So you might verify if that sequence really happened. Possible solutions are for us to force the MSG MessageBox to be amodal so it must be used. But also your app should probably keep track of when it launched the GCode interpreter and disable many of the buttons that could interfere with the Interpreter or cause it to be re-entered. KMotionCNC sets a flag called ThreadIsExecuting which is set when Gcode is launched ornd cleared on the GCode Complete Callback.
> Â
> Or maybe you have any other thoughts or ideas.
> Â
> Regards
> TK
> Â
>
>
> ________________________________
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Wednesday, February 1, 2012 4:59 PM
> Subject: [DynoMotion] A Strange Thing Happened....
>
>
> Â
> Tom,
>
> I was running the machine today, and something odd/scary happened. It had stopped mid-program for a toolchange, and there was a dialog up (from a MSG comment) prompting me to change tools. Instead, I clicked Stop (which does an Interpreter.Halt()), without dismissing the dialog. So far, so good. I then clicked on an on-screen button that does the MDI command "G0 X0 Y0 Z0". But ALL FOUR axes moved! It looked like the A axis was doing a G43 (which was the NEXT line in the program). X/Y/Z sailed right past their zero positions, and it appeared to me they, too, were going to the position in the program, rather than the position in the MDI command. Any idea a) How this happened, and b) How I cam prevent it from ever happening again? Had I not had my finger on E-Stop, it would've done some serious damage.
>
> Regards,
> Ray L.
> |
|
| Group: DynoMotion |
Message: 3668 |
From: Brad Murry |
Date: 2/1/2012 |
| Subject: Re: A Strange Thing Happened.... |
Hello Ray, For Modals- look at KM_Controller.Interpreter.SetupParams You can get a list of active G and M codes -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of himykabibble
Sent: Wednesday, February 01, 2012 7:09 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Re: A Strange Thing Happened.... Tom,
What you describe is basically what I decided must have happened. I can see no other explanation for the A axis moving, as it is ONLY moved by tool comp commands. I do currently disable most of the controls when a program is running, but I want the Stop button to be sort a more polite E-Stop - whenever it is enabled (which is whenever the interpreter is running), you should be able to push it and be sure the machine will stop, and end up in a state from which you can resume what you were doing. I don't want the interpreter state to be totally tossed, but it would be perfectly acceptable to flush any commands in process, and re-start at a line boundary. Is there a way to accomplish that? I use this often when running a program for the first time. If I see it go off-course, I'd like to hit Stop, select the program line to resume from, and re-start the interpreter from that line. This is the behavior Mach3 provides, and I found it very useful.
While you're here, is there a way to fetch the currently active modal states from the interpreter? I'm not seeing anything in the APIs. I believe I did see something in the interpreter source code that is exactly what I need, but it doesn't appear to be brought out through the APIs.
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
> Â
> I think I have a few ideas, but can you reproduce this? (Maybe with your amplifiers turned off).
> Â
> But I just tested with KMotionCNC and noted several things. The "MSG" dialog box is not currently forced to be on top of all other Windows. The expectation is that you either Cancel (Abort) or OK (Continue) using the Displayed Dialog Box. But it seems you clicked on your Screen which probably hid the Interpreter's MessageBox behind your Screen.
> Â
> Calling Interpreter.Halt() basically sets a flag in the Interpreter and In CoordMotion to request that GCode Execution Thread to do the Halt Sequence ASAP. The Halt is tested at various places while executing. But in this case the the Interpreter was frozen in the MessageBox so the Halt was not yet detected.
> Â
> You then issued an MDI command to execute some GCode which would cause the GCode Interpreter to be re-entered. This could likely result in unpredictable behavior.
> Â
> So you might verify if that sequence really happened. Possible solutions are for us to force the MSG MessageBox to be amodal so it must be used. But also your app should probably keep track of when it launched the GCode interpreter and disable many of the buttons that could interfere with the Interpreter or cause it to be re-entered. KMotionCNC sets a flag called ThreadIsExecuting which is set when Gcode is launched ornd cleared on the GCode Complete Callback.
> Â
> Or maybe you have any other thoughts or ideas.
> Â
> Regards
> TK
> Â
>
>
> ________________________________
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Wednesday, February 1, 2012 4:59 PM
> Subject: [DynoMotion] A Strange Thing Happened....
>
>
> Â
> Tom,
>
> I was running the machine today, and something odd/scary happened. It had stopped mid-program for a toolchange, and there was a dialog up (from a MSG comment) prompting me to change tools. Instead, I clicked Stop (which does an Interpreter.Halt()), without dismissing the dialog. So far, so good. I then clicked on an on-screen button that does the MDI command "G0 X0 Y0 Z0". But ALL FOUR axes moved! It looked like the A axis was doing a G43 (which was the NEXT line in the program). X/Y/Z sailed right past their zero positions, and it appeared to me they, too, were going to the position in the program, rather than the position in the MDI command. Any idea a) How this happened, and b) How I cam prevent it from ever happening again? Had I not had my finger on E-Stop, it would've done some serious damage.
>
> Regards,
> Ray L.
>
|
|
| Group: DynoMotion |
Message: 3669 |
From: himykabibble |
Date: 2/1/2012 |
| Subject: Re: A Strange Thing Happened.... |
Brad,
Geez! I could swear I looked there....
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Hello Ray,
>
>
>
> For Modals- look at KM_Controller.Interpreter.SetupParams
>
>
>
> You can get a list of active G and M codes
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Wednesday, February 01, 2012 7:09 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: A Strange Thing Happened....
>
>
>
>
>
> Tom,
>
> What you describe is basically what I decided must have happened. I can see
> no other explanation for the A axis moving, as it is ONLY moved by tool comp
> commands. I do currently disable most of the controls when a program is
> running, but I want the Stop button to be sort a more polite E-Stop -
> whenever it is enabled (which is whenever the interpreter is running), you
> should be able to push it and be sure the machine will stop, and end up in a
> state from which you can resume what you were doing. I don't want the
> interpreter state to be totally tossed, but it would be perfectly acceptable
> to flush any commands in process, and re-start at a line boundary. Is there
> a way to accomplish that? I use this often when running a program for the
> first time. If I see it go off-course, I'd like to hit Stop, select the
> program line to resume from, and re-start the interpreter from that line.
> This is the behavior Mach3 provides, and I found it very useful.
>
> While you're here, is there a way to fetch the currently active modal states
> from the interpreter? I'm not seeing anything in the APIs. I believe I did
> see something in the interpreter source code that is exactly what I need,
> but it doesn't appear to be brought out through the APIs.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> > Â
> > I think I have a few ideas, but can you reproduce this? (Maybe with your
> amplifiers turned off).
> > Â
> > But I just tested with KMotionCNC and noted several things. The "MSG"
> dialog box is not currently forced to be on top of all other Windows. The
> expectation is that you either Cancel (Abort) or OK (Continue) using the
> Displayed Dialog Box. But it seems you clicked on your Screen which
> probably hid the Interpreter's MessageBox behind your Screen.
> > Â
> > Calling Interpreter.Halt() basically sets a flag in the Interpreter and In
> CoordMotion to request that GCode Execution Thread to do the Halt Sequence
> ASAP. The Halt is tested at various places while executing. But in this
> case the the Interpreter was frozen in the MessageBox so the Halt was not
> yet detected.
> > Â
> > You then issued an MDI command to execute some GCode which would cause the
> GCode Interpreter to be re-entered. This could likely result in
> unpredictable behavior.
> > Â
> > So you might verify if that sequence really happened. Possible solutions
> are for us to force the MSG MessageBox to be amodal so it must be used.Â
> But also your app should probably keep track of when it launched the GCode
> interpreter and disable many of the buttons that could interfere with the
> Interpreter or cause it to be re-entered. KMotionCNC sets a flag called
> ThreadIsExecuting which is set when Gcode is launched ornd cleared on the
> GCode Complete Callback.
> > Â
> > Or maybe you have any other thoughts or ideas.
> > Â
> > Regards
> > TK
> > Â
> >
> >
> > ________________________________
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Sent: Wednesday, February 1, 2012 4:59 PM
> > Subject: [DynoMotion] A Strange Thing Happened....
> >
> >
> > Â
> > Tom,
> >
> > I was running the machine today, and something odd/scary happened. It had
> stopped mid-program for a toolchange, and there was a dialog up (from a MSG
> comment) prompting me to change tools. Instead, I clicked Stop (which does
> an Interpreter.Halt()), without dismissing the dialog. So far, so good. I
> then clicked on an on-screen button that does the MDI command "G0 X0 Y0 Z0".
> But ALL FOUR axes moved! It looked like the A axis was doing a G43 (which
> was the NEXT line in the program). X/Y/Z sailed right past their zero
> positions, and it appeared to me they, too, were going to the position in
> the program, rather than the position in the MDI command. Any idea a) How
> this happened, and b) How I cam prevent it from ever happening again? Had I
> not had my finger on E-Stop, it would've done some serious damage.
> >
> > Regards,
> > Ray L.
> >
> |
|
| Group: DynoMotion |
Message: 3671 |
From: Tom Kerekes |
Date: 2/2/2012 |
| Subject: Re: A Strange Thing Happened.... |
Hi Ray,
That is a good question. I think KMotionCNC has one of the best halt/resume capabilities. This feature is one of the most complex of anything in KMotion. A Halt issues a hardware feedhold to come to an immediate stop along the current path. The interpreter is then aborted. The interpreter is backed up (possibly hundreds of lines) from its lookahead position to within the line of GCode where the machine actually was. Note this is not on a GCode line boundary as a resume from a GCode line boundary would not always work properly. KMotionCNC
then allows jogging and offset changes. Hitting resume (Execute) will then (if the machine position has been altered) offer a number of options to resume (a safez motion, turn the spindle back on, restore the feedrate, etc).
However "Run from here" we don't really have, and as far as I know no one else has one that always works perfectly either. In KMotionCNC you can change the GCode line to someplace else and continue, but it is up to you to make sure it makes sense. So for example switching to some other line of GCode that expects to have a different tool loaded at that point wouldn't make sense. There are several problems. #1 is that the Interpreter state might not match what the state would be if the program had executed normally from the beginning up to that point. I think some systems might try to re-execute the code up to that point from the beginning. But
I don't think that works well for several reasons. It might take a long time. There might be tool changes and probes and subroutines involved. But we could probably actually do this pretty easily as we already maintain a history of the Interpreter state that we use for the rewind through the lookahead. So as long as the new line was "close by" and backwards it would work. But then the second issue is after we have the state we would like to be in the actual machine configuration may not match it. Maybe this is not too hard to resolve. Maybe just make sure the correct tool is loaded and we do a save z move to where we want to resume.
What has been your experience?
Regards
TK
| Group: DynoMotion |
Message: 3672 |
From: himykabibble |
Date: 2/2/2012 |
| Subject: Re: A Strange Thing Happened.... |
Tom,
I understand doing a true "RunFromHere" is complex, but that's not what I'm asking for. In fact, I never used that feature on Mach3, expressly because it WAS anything but reliable, and would often start off doing something very wrong. All I want to be able to do is interrupt execution with a Stop, then give it a line number, and pickup from that line. If coolant/spindle/etc. need to be turned back on at that point, that can be up to the user. Obviously, I can do part of that by, rather than simply resuming execution, specifying the line number to resume from. But how do I ensure any moves in process are completely flushed, so I don't see the kind of thing I saw yesterday?
On a related topic, I find if I load a program, set a random line number, then try to do a Start or Step, it doesn't always work right. The most common problem I see is that the interpreter starts, then stops, without having DONE anything. It will always correctly step over comment lines, and non-motion lines (Fs, Ms, G20s, etc.), but when it gets to the first G0, G1, G2, G3, it doesn't actually move, and the line count does not increment. If, however, I do a Start, FeedHold, then Stop, I can then select a line and Start or Step from there with no problems. Any ideas what I'm missing? There must be some bit of setup I'm not doing right.
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
> Â
> That is a good question. I think KMotionCNC has one of the best halt/resume capabilities.  This feature is one of the most complex of anything in KMotion. A Halt issues a hardware feedhold to come to an immediate stop along the current path. The interpreter is then aborted. The interpreter is backed up (possibly hundreds of lines) from its lookahead position to within the line of GCode where the machine actually was. Note this is not on a GCode line boundary as a resume from a GCode line boundary would not always work properly. KMotionCNC then allows jogging and offset changes. Hitting resume (Execute) will then (if the machine position has been altered) offer a number of options to resume (a safez motion, turn the spindle back on, restore the feedrate, etc).
> Â
> However "Run from here" we don't really have, and as far as I know no one else has one that always works perfectly either. In KMotionCNC you can change the GCode line to someplace else and continue, but it is up to you to make sure it makes sense. So for example switching to some other line of GCode that expects to have a different tool loaded at that point wouldn't make sense. There are several problems. #1 is that the Interpreter state might not match what the state would be if the program had executed normally from the beginning up to that point. I think some systems might try to re-execute the code up to that point from the beginning. But I don't think that works well for several reasons. It might take a long time. There might be tool changes and probes and subroutines involved. But we could probably actually do this pretty easily as we already maintain a history of the Interpreter state that we use for the rewind through the
> lookahead. So as long as the new line was "close by" and backwards it would work.  But then the second issue is after we have the state we would like to be in the actual machine configuration may not match it. Maybe this is not too hard to resolve. Maybe just make sure the correct tool is loaded and we do a save z move to where we want to resume.
> Â
> What has been your experience?
> Â
> Regards
> TK
> Â
> Â
>
>
> ________________________________
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Wednesday, February 1, 2012 6:09 PM
> Subject: [DynoMotion] Re: A Strange Thing Happened....
>
>
> Â
> Tom,
>
> What you describe is basically what I decided must have happened. I can see no other explanation for the A axis moving, as it is ONLY moved by tool comp commands. I do currently disable most of the controls when a program is running, but I want the Stop button to be sort a more polite E-Stop - whenever it is enabled (which is whenever the interpreter is running), you should be able to push it and be sure the machine will stop, and end up in a state from which you can resume what you were doing. I don't want the interpreter state to be totally tossed, but it would be perfectly acceptable to flush any commands in process, and re-start at a line boundary. Is there a way to accomplish that? I use this often when running a program for the first time. If I see it go off-course, I'd like to hit Stop, select the program line to resume from, and re-start the interpreter from that line. This is the behavior Mach3 provides, and I found it very useful.
>
> While you're here, is there a way to fetch the currently active modal states from the interpreter? I'm not seeing anything in the APIs. I believe I did see something in the interpreter source code that is exactly what I need, but it doesn't appear to be brought out through the APIs.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> > ÃÂ
> > I think I have a few ideas, but can you reproduce this?ÃÂ (Maybe with your amplifiers turned off).
> > ÃÂ
> > But I just tested with KMotionCNC and noted several things.ÃÂ The "MSG" dialog box is not currently forced to be on top of all other Windows.ÃÂ The expectation is that you either Cancel (Abort) or OK (Continue) using the Displayed Dialog Box.ÃÂ But it seems you clicked on your Screen which probably hid the Interpreter's MessageBox behind your Screen.
> > ÃÂ
> > Calling Interpreter.Halt() basically sets a flag in the Interpreter and In CoordMotion to request that GCode Execution Thread to do the Halt Sequence ASAP.ÃÂ The Halt is tested at various places while executing.ÃÂ But in this case the the Interpreter wasÃÂ frozen in the MessageBox so the Halt was not yet detected.
> > ÃÂ
> > You then issued an MDI command to execute some GCode which would cause the GCode Interpreter to be re-entered.ÃÂ This could likely result in unpredictable behavior.
> > ÃÂ
> > So you might verify if that sequence really happened.ÃÂ Possible solutions are for us to force the MSG MessageBox to be amodal so it must be used.ÃÂ But also your app should probably keep track of when it launched the GCode interpreter and disable many of the buttons that could interfere with the Interpreter or cause it to be re-entered.ÃÂ KMotionCNC sets a flag called ThreadIsExecuting which is set when Gcode is launched ornd cleared on the GCode Complete Callback.
> > ÃÂ
> > OrÃÂ maybeÃÂ you have any other thoughts or ideas.
> > ÃÂ
> > Regards
> > TK
> > ÃÂ
> >
> >
> > ________________________________
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Wednesday, February 1, 2012 4:59 PM
> > Subject: [DynoMotion] A Strange Thing Happened....
> >
> >
> > ÃÂ
> > Tom,
> >
> > I was running the machine today, and something odd/scary happened. It had stopped mid-program for a toolchange, and there was a dialog up (from a MSG comment) prompting me to change tools. Instead, I clicked Stop (which does an Interpreter.Halt()), without dismissing the dialog. So far, so good. I then clicked on an on-screen button that does the MDI command "G0 X0 Y0 Z0". But ALL FOUR axes moved! It looked like the A axis was doing a G43 (which was the NEXT line in the program). X/Y/Z sailed right past their zero positions, and it appeared to me they, too, were going to the position in the program, rather than the position in the MDI command. Any idea a) How this happened, and b) How I cam prevent it from ever happening again? Had I not had my finger on E-Stop, it would've done some serious damage.
> >
> > Regards,
> > Ray L.
> >
> |
|
| | | |
